With the advent of 3G mobile terminals, particularly UMTS and GPRS-enabled terminals, the ability for greater functionality to be performed by such terminals, in addition to standard voice calls, has become possible.
For instance, end-to-end client-server systems have been developed for use in conjunction with mobile terminals. Such systems enable enterprise/back-end databases and applications to be represented and manipulated on mobile devices in a secure fashion. These systems provide field workers (i.e. those working off-site) with the ability to access certain back-end business systems and databases, for example.
The client component of such end-to-end systems comprise an application installed on one or more mobile terminals. Such mobile terminal applications typically perform one or more of the following functions:                Mediating between the mobile device and the enterprise system to transfer only the data that is required by the device;        Providing secure access to applications/servers only by users who are authorised to use those applications;        Keeping data on the mobile device and the enterprise system synchronized and up to date; and/or        Providing a suitable user interface to render data and other functionality to the terminal in a format that is suitable for the terminal.        
To date, in order to ensure a suitable level of security, an entity, such as a telecommunications network service provider, hosts a Network Applications Manager (NAMan) server, allowing only authorised terminal users the ability to remotely access one or more back-end servers registered with the NAMan server. Such systems can be configured so that they are accessed by multiple users from multiple organisations, or by multiple users from a single organisation, which would be the case in the situation of company employees remotely accessing their company's back-end databases.
With reference to FIG. 1, the operation of such a system will be explained, where a user of a mobile terminal 10 wishes to access a backend/enterprise system for which they are registered to use. The user of the mobile terminal 10 would activate the appropriate client application preinstalled on the mobile terminal 10. The installed application will typically have a Graphical User Interface (GUI) in order to provide a user-friendly interface. The application requests a password for enabling the client application and the user enters this password. The client application checks the password against its internal database. The client application may then additionally request a password for the NAMan server.
The client application has an Access Point Name (APN) for the NAMan server 12, in order to enable the client application to access the NAMan server 12, serving as a gateway to the back-end systems 13, 14 and 15. The APN indicates to the GGSN which network/sub-network to give the user access to.
Therefore, once the client application is activated, the terminal connects to the network using its provisioned APN by creating a PDP context. The PDP context is forwarded to the service provider's GGSN 11, which verifies that the user is a subscriber to the NAMan server, identified by the APN, using a RADIUS (Remote Authentication Dial In User Service) server. In this regard, as security requirements dictate that a user should be authenticated before it connects to the NAMan server, the MSISDN (Mobile Subscriber International Subscriber Identity Number) associated with the mobile terminal is extracted from the PDP context and presented to the RADIUS server for an authentication check. The MSISDN is a unique number on the network and may be stored on the user's SIM card. The RADIUS server stores the MSISDNs of users allowed access to each of the backend system(s).
Once the user is validated, the GGSN 11 forwards the access request (including the NAMan password, if required) to the NAMan server 12, which allows the mobile terminal 10 access to the appropriate back-end server 13, 14 or 15. The client application may additionally request a username and password for back-end server 13, 14 or 15. The appropriate back-end server will be that which corresponds to the client application activated on the terminal 10. The GGSN 11 will route traffic received from the NAMan server to the terminal.
Once a user has gained access to the backend server, they are able to retrieve any data that they require and also, where they have been previously been using their client application “off-line”, synchronise the data on their terminal with the backend server. To achieve synchronisation, any changed application data is uploaded to the NAMan server for onwards storage in the enterprise/backend system. The NAMan server does not permanently store application data; it merely acts as a conduit for data being transferred to the backend server. Communications between the NAMan server and the application on the mobile terminal typically are undertaken by the exchange of XML messages.
In terms of providing “off-line” functionality, the terminal application may be configured to allow the user to access and manipulate data previously downloaded from the backend system—such as a list of jobs that the user needs to perform that day and/or specific customer data. For instance, the user may mark off the jobs as each is done and also update the customer data, such as by correcting address details and updating their product/service requirements. Where this is performed offline, the changes are only effected in regard to the data on the terminal. When the user next goes “online”, by performing the verification through the NAMan server, as described above, they are then able to again directly access the back-end system, and the data on the terminal can be synchronised with the backend data.
This approach works well where all remote users of the system subscribe to the particular telecommunications service provider providing the secure access to the backend system via their GGSN 11. In this regard, the service provider's GGSN has been configured to provide the RADIUS server with the data necessary for securely verifying the user/terminal as an authorised user, by extracting the user's MSISDN from their access request PDP context.
However, in today's competitive mobile telecommunications marketplace, many companies are not requiring all of their employees who have a company mobile terminal to subscribe to the same service provider, so for example, some employees may subscribe to Vodafone, whilst others subscribe to BT and Orange. In such a situation, requests for access to the NAMan server 12 would not necessarily go through the managing service provider's GGSN 11, which would be required to obtain the appropriate level of user verification, since it is specially configured to only forward requests from terminals with authorised MSISDNs.
Whilst it may be possible for access requests to be alternatively routed through another service provider's network to the managing service provider's GGSN 11, the GGSN 11 would not have the same degree of verification control, as it would only be able to have access to the MSISDN of the terminal by requesting the other network to provide it. This is not desirable, as the other service provider may not cooperate and refuse to provide the MSISDN information. Further, even if the other service provider did provide the MSISDN, the service provider managing the server 12 does not have full control over the verification process, and hence is more susceptible to hacking attacks.
A similar problem exists in relation to roaming users. Under the current arrangement, since the user needs to access the backend server via GGSN 11 of the managing network operator, if the user is in a country where the network operator does not have a presence or network operator does not have roaming connectivity, the user will not be able to directly access the back-end system via GGSN 11, and would need cooperation from the local service providers in order to obtain the MSISDN for the verification process.
There is therefore a need for an end-to-end client-server system that can operate more securely over different service providers/network operators or over otherwise non-compatible networks.